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Sir: 



In response to the Final Official Action mailed September 29, 2003, applicants submit the 
following arguments. 

Reconsideration and allowance of the above-referenced application are respectfully 
requested. Claims 1-29 are pending in the application. 

Claims 1-6, 8, 1 1-23, 25, and 28-29 stand rejected under 35 USC § 102(e) in view of U.S. 
Patent No. 6,507,817 to Wolfe et al. This rejection is respectfully traversed. The arguments 
submitted July 11, 2003 are incorporated in their entirety herein by reference. The following 
comments elaborate on the arguments in view of the Final Action. 

First, the Final Action asserts that "Applicants still have failed to clearly disclose the novelty 
of the invention and identify specific [sic] limitation, which would define patentable distinction over 



prior art.'* In response, the following clarification is submitted: 

Wolfe et al. does not disclose the claimed "identifying the messaging operation in the 
application server by interpreting the audio file" as specified in independent claims 1 and 18; 

Wolfe et al. does not disclose the claimed "receiving an HTTP request ... having an audio 
file ... specifying a messaging operation" and "outputting a selected function call specifying the 
[i.e., derived from the audio file] messaging operation" as specified in claims 1 1 and 14; 

Wolfe et al. does not disclose the claimed browser "generating a first file, that specifies 
a messaging operation ... based on voice signals received from a user and that specify the 
messag in g operation " and "receiving an HTML page from the application server including a 
second file having an indication whether the messaging operation ... was executed by the 
messaging server" as specified in claim 28. 

The Final Action improperly disregards Applicant's arguments and the explicit teachings of 
the applied reference: The Final Action fails to even acknowledge Applicant's arguments that: 

(1) Wolfe et al. does not disclose use of a speech recognition system; 

(2) Wolfe et al does not use the disclosed voice resource for speech recognition, but rather 
uses the voice resource for controlling playback of a supplied audio file under the control of XML 
tags within the HTML pages. 

Hence, the Final Action is improper because it fails to answer all material traversed (See 
MPEP 707.07(0 entitled Answer All Material Traversed: "Where the applicant traverses any 
rejection, the examiner should, if he or she repeats the rejection, take note of the applicant's 
argument and answer the substance of it." 

The Final Action applies a strained interpretation of Wolfe et al. in its Response to 
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Arguments to assert that Wolfe et al. discloses disclose interpreting voice signals: 

"...the application server receives a HTTP requests [sic] from a PC-based web browser which 
contain an [sic] audio content ... the voice application server accesses a selected XML 
document that defines an application operation to be performed, based on parameters 
specified with [sic] the HTTP request...." 

The Final Action has demonstrated only that: (1) Wolfe et al. teaches that the application 
server receives an HTTP request having audio content; and that (2) Wolfe et al. also teaches that the 
HTTP request specifies parameters that are used to access a selected XML document that defines 
an application operation. 

However, the Final Action fails to identify the most critical component: that the parameter 

used to access the selected XML document is specified within the audio content. In fact, the cited 

portions of Wolfe et al. read as follows: 

As shown in FIG. 1, each of the clients (tiny clients, skinny clients, thin clients and fat 
clients) are able to communicate via a single, unified architecture 60 that enables voice 
communications services between different clients, regardless of whether the client 
actually has browser capabilities. Hence, the fat client 42a and the thin client 42b are able 
to execute voice enabled web applications without any hardware modification or any 
modification to the actual browser; rather, the browsers 56 in the clients 42a and 42b 
merely are provided with an executable voice resource configured for providing browser 
audio control, described below. 

(Col. 4, 28-40) 

The proxy browser 62 and the web browsers 56 within the fat client 42a and the thin 
client 42b execute voice enabled web applications by sending data and requests to a web 
server 64, and receiving hypertext markup language (HTML) web pages from the web 
server 64, according to hypertext transport protocol (HTTP). The web server 64 serves as 
an interface between the browsers and an application server 66 that provides an 
executable runtime environment for XML voice applications 68. For example, the web 
server 64 may access the application server 66 across a common gateway interface (CGI) 
as illustrated in FIG. 2, by issuing a function call across an application programming 
interface (API), or by requesting a published XML document or an audio file requested 
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by one of the browsers 56 or 62. The application server 66, in response to receiving a 
request from the web server 64, may either supply the requested information in the form 
of an HTML page having XML tags for audio control by a voice resource within the 
browser, or may perform processing and return a calculated value to enable the browser 
56 or 62 to perform additional processing. 

(Col. 5, lines 16-37) (emphasis added). 

Once the submitting party posts the form to the web server 64', the CGI parses the form 
to determine status and generates a message (e.g., e-mail) to the approving party specified 
in the completed form using database APIs 82 (e.g., SMTP service for storage of e-mail 
messages in IMAP 86). 

With regard to form approval, the application server 66 receives, via the web server 64, 
HTTP requests from either a PC-based web browser 56 capable of supplying full media 
content (e.g., audio, text, images, and streaming video), or a lightweight or proxy browser 
62 configured for serving as an HTTP interface for a user input device, such as a 
telephone 18, having limited media capabilities (e.g., audio only). In response to 
receiving the HTTP requests, the voice application server 66 accesses a selected XML 
document 68 that defines an application operation to be performed, based on parameters 
specified within the HTTP request, and based on application state determined from 
accessing a brownie, assuming the HTTP request specifies a valid session identifier . As 
described below, the application runtime environment within the voice application server 
66 parses the XML tags within the accessed XML document 68, and dynamically 
generates a first HTML page having XML tags that specify media content (e.g., ,wav 
files) and control information for playing the media files by the corresponding browser. 
The proxy browser 62 is configured for parsing a prescribed portion of a prescribed group 
of media tags. 

The voice application server 66 is configured for accessing service application 
programming interfaces (APIs) 82 to. external resources based on prescribed procedures 
that may be called during parsing of an XML tags in a selected XML document 68. 

(Col. 6, lines 14-44) 

As apparent from the foregoing, Wolfe et al. does not disclose the claimed features of: 
receiving an HTTP request having an audio file specifying an messaging operation; interpreting 
an audio file in order to identify the messaging operation; or generating a file that specifies a 
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messaging operation based on user voice signals that specify the messaging operation, as 
claimed. 

Hence, the rejection should be withdrawn because it fails to demonstrate that Wolfe et al. 
discloses each and every element of the claim . See MPEP 2131. "The identical invention must 
be shown in as complete detail as is contained in the ... claim." Richardson v. Suzuki Motor Co. . 
868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). "Anticipation cannot be 
predicated on teachings in the reference which are vague or based on conjecture." 
Studiengesellschaft Kohle mbH v. Dart Industries. Inc. . 549 F. Supp. 716, 216 USPQ 381 (D. 
Del. 1982), affd. . 726 F.2d 724, 220 USPQ 841 (Fed. Cir. 1984). 

For these and other reasons, the § 102(e) rejection should be withdrawn. 

The indication of allowable subject matter in claims 7, 9, 10, 24, 26, and 27 is 
acknowledged and appreciated. It is believed that these claims are in allowable form in view of 
the foregoing. 

In view of the above, it is believed this application is and condition for allowance, and 
such a Notice is respectfully solicited. 
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To the extent necessary, Applicant petitions for an extension of time under 37 C.F.R. 
1 .136. Please charge any shortage in fees due in connection with the filing of this paper, 
including any missing or insufficient fees under 37 C.F.R. 1.17(a), to Deposit Account No. 
50-1 130, under Order No. 95-423, and please credit any excess fees to such deposit account. 



Customer No. 23164 

(202) 261-1059 

Date: December 1, 2003 

(November 29, 2003 = Saturday) 
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Respectfully submitted, 




Leon R. Turkevich 
Registration No. 34,035 



